Technical Field
The present disclosure relates generally to computer aided design (CAD), and more specifically to techniques for converting CAD descriptions.
Background Information
Many computer aided design (CAD) applications store CAD descriptions of physical structures (e.g., buildings, civil infrastructure projects, etc.) using a specific storage format. One type of storage format (referred to herein as a “file-based storage format”) involves one or more files (e.g., a root file and one or more attached files) that maintain a series of data structures that represent elements organized into models, associated with levels that help define graphical views.
Elements generally describe individual units of the structure. For example, in a simple CAD description of a building, elements may represent walls, doors, windows, furniture, etc. Models generally group together related elements into larger units, effectively “owning” a set of elements. A CAD description consists of at least one model (e.g., a root model), and often a number of additional models (e.g., attached models) organized under the root model using attachments to form a model graph. For example, in a simple CAD description of a building, a root model may represent an overall building, and may reference, via attachments, attached models that represent individual floors, each attached model owning elements representing walls, doors, windows, furniture, etc. disposed on a respective floor. A level generally describes selected elements that should be displayed (e.g., “turned on”) and, in some cases, symbology (e.g., color, line weight, line style etc.) that controls their visual appearance. For example, in a simple CAD description of a building, a level may include all the elements that represent windows, and indicate that such elements should be displayed with black, thin, dashed lines. Graphical views generally are representations of selected elements shown with certain symbology. For example, in a simple example CAD description of a building, a particular graphical view may show elements that represent walls and windows, with walls represented with black, bold, solid lines and windows represented in black, thin, dashed lines. Graphical views may be defined by attachment paths from a root model in the model graph, with the symbology and range of elements indicated by elements of the model graph, the levels to which the elements belong, and by attachment specific copies of levels (“attached levels”) that override the display status and symbology of the levels. Such an arrangement may be better understood by reference to the example in FIG. 1
FIG. 1 is a data structure diagram 100 of a portion of an example first storage format (e.g., a file-based storage format) for a CAD description. The data structure diagram 100 may be consistent with the DgnV8 format, compatible with CAD applications available from Bentley Systems, Inc. of Exton, Pa. However, it should be understood that similar formats may be used in other CAD applications, available from other vendors. The data structure diagram 100 represents a number of data items, embodied using various data structures. In the data structure diagram 100, a file data structure 110 serves as a header of each file (e.g., a root file or attached file), and includes a name field that indicates a unique human readable name for the file, a models field that references model data structures contained in the file, and a levels field that references level data structures contained in the file. Each model data structure 120 represents an individual model (e.g., a root model or an attached model) and includes a model ID field that indicates a unique identifier for the model, a name field that indicates a unique human readable name for the model, a file field that references the owning file, and elements fields that reference element data structures owned by the model. Each model may be located in a spatial coordinate system used to define the arrangement of its elements. Each element data structure 130 represents an individual element owned by a model and includes an element ID field that indicates a unique identifier for the element within the file, a model ID field that indicates the owning model data structure, a level field that indicates a level associated with the element, a data field that includes information describing the unit of the physical structure being represented by the element, and a DHDR field that indicates an associated DHDR data structure. Each DHDR data structure 140 indicates range and symbology information that describes how the owning element should be rendered, including a color field, a weight field and a style field. Each element data structure may reference a level data structure 150 for a level to which it belongs. Each level data structure 150 represents a level to which elements may belong, including a level ID field that indicates a unique identifier for the level, a name field that indicates a unique human-readable name for the level, a display field that indicates whether elements on the level should be displayed (e.g., “turned on”), and symbology fields, such as a color field, a weight field and a style field, that indicate overrides to the symbology of individual elements of the level.
A model graph is defined using attachment data structures that defines the ownership structure of models and the presence of any attached levels. Each attachment data structure 160 includes a file name field that references the file containing the attached model, a model name field that references the attached model, a transform field that indicates any spatial transform that may be applied to relate a spatial coordinate systems used by the attached model to that of the owning model, and attached level fields that references attached levels that may be used with the attachment. Each attached level data structure 170 defines overrides for an underlying level, and includes a level ID field that identifies the attached level, a display field that indicates whether the level should be displayed, and symbology fields, such as a color field, a weight field and a style field, that may override the symbology of the level. A graphical view may be defined in the model graph by a view data structure 190 that references a particular model data structure 120 that serves as a root for attachment paths of the model graph of the view.
In some cases, it may be necessary to convert a CAD description using the first storage format (e.g., the file-based storage format) depicted in FIG. 1 to a second storage format. Such conversion may be needed to enable interoperability between different CAD applications, or different versions of the same CAD application that may utilize different storage formats, among other purposes. However, certain challenges have been encountered in designing such a converter.
A first challenge involves dealing with spatial ambiguities. As mentioned above, models in the file-based storage format may each use their own spatial coordinate system (i.e. there may be no predetermined spatial relationship with other models, and instead relationships may be defined using transforms of attachments). As such, the CAD description may be thought of as a collection of individual “fragments.” Further, models in the first storage format may attach to any other model. In effect, the “fragments” can be connected in a myriad of different ways conveying different meanings. Given such a structure, it may be difficult to derive a single, cohesive representation from the connected “fragments”.
One specific source of difficulties may be scenarios where there are multiple root models and cycles within the model graph. For example, a first root model may be used to represent the design in physical space, using a first set of transforms to relate a set of attached models. A second root model may be used to represent a graphical view having a certain composition and use a second set of transform (e.g., selected for presentation purposes) to relate those same set of attached models. Thereby multiple root models may exist. Further, a first model (e.g., a first attached model) may attach to a second model (e.g., a second attached model), and the second model may also attach, directly or via recursion, to the first model. Thereby cycles may exist.
Another specific source of difficulties may be scenarios where there are multiple attachment paths to the same attached model from a single root model, but using different transforms, causing there to be multiple instantiations of elements. For example, a root model may attach to an attached model using a first transform along one path of the model graph and attach to the same attached model using a second, different transform along another path of the model graph, thereby duplicating the attached models elements, but in different locations.
A second challenge involves accurately preserving human-readable names and information relationships related to the per-file levels in the pre-conversion CAD description into a post-conversion CAD description that has only one set of levels. For example, while a converter may preserve the visual appearance of a graphical view, human-readable names and information relationships associated with attached levels from the model graph may be lost. A user looking to the post-conversion CAD description may not see the human-readable names and information relationships they are familiar with, and therefor may have difficulty interpreting or manipulating the design.
Accordingly, there is a need for improved techniques for converting a CAD description maintained in a first storage format (e.g., a file-based storage format) to a second storage format that may address challenges introduced by spatial ambiguities in the model graph of the first storage format and/or may accurately preserve human-readable names and information relationships where the second storage format does not use the same structures.